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1 INTRODUCTION 


The DARPA Catenet is expected to be a continuously expanding 
system, with more and more hosts on more and more networks 
participating in it. Of course, this will require more and more 
gateways. In the past, such expansion has taken place ina 
relatively unstructured manner. New gateways, often containing 
radically different software than the existing gateways, would be 
added and would immediately begin participating in the common 
routing algorithm via the GGP protocol. However, as the internet 
grows larger and larger, this simple method of expansion becomes 


less and less feasible. There are a number of reasons for this: 


- the overhead of the routing algorithm becomes excessively 


large; 


- the proliferation of radically different gateways 
participating in a single common routing algorithm makes 
maintenance and fault isolation nearly impossible, since 
it becomes impossible to regard the internet as an 


integrated communications system; 


- the gateway software and algorithms, especially the 
routing algorithm, become too rigid and inflexible, since 
any proposed change must be made in too many different 


places and by too many different people. 
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In the future, the internet is expected to evolve into a set 
of separate domains or "autonomous systems", each of which 
consists of a set of one or more relatively homogeneous gateways. 
The protocols, and in particular the routing algorithm which 
these gateways use among themselves, will be a private matter, 


and need never be implemented in gateways outside the particular 


domain or system. 


In the simplest case, an autonomous system might consist of 
just a single gateway connecting, for example, a local network to 
the ARPANET. Such a gateway might be called a "stub gateway", 
since its only purpose is to interface the local network to the 
rest of the internet, and it is not intended to be used for 
handling any traffic which neither originated in nor is destined 
for that particular local network. In the near-term future, we 
will begin to think of the internet as a set of autonomous 
systems, one of which consists of the DARPA gateways on ARPANET 
and SATNET, and the others of which are stub gateways to local 
networks. The former system, which we shall call the "core" 
system, will be used as a transport or "long-haul" system by the 


latter systems. 


Ultimately, however, the internet may consist of a number of 
co-equal autonomous systems, any of which may be used (with 


certain restrictions which will be discussed later) as a 


RFC 827 Bolt Beranek and Newman Inc. 
Eric C. Rosen 


transport medium for traffic originating in any system and 
destined for any system. When this more complex configuration 
comes into being, it will be inappropriate to regard any one 
autonomous system as a "core" system. For the sake of 
concreteness, however, and because the initial implementations of 
the Exterior Gateway Protocol are expected to focus on the the 
case of connecting "stub gateways" to the DARPA gateways on 
ARPANET and SATNET, we will often use the term "core" gateways in 


our examples and discussion. 


The purpose of the Exterior Gateway Protocol (EGP) is to 
enable one or more autonomous systems to be used as transport 
media for traffic originating in some other autonomous system and 
destined for yet another, while allowing the end-user to see the 
composite of all the autonomous systems as a single internet, 
with a flat, uniform address space. The route which a datagram 
takes through the internet, and the number of autonomous systems 
which it traverses, are to be transparent to the end-user 


(unless, of course, the end-user makes use of the IP "source 


route" option). 


In describing the Exterior Gateway Protocol, we have 
deliberately left a great deal of latitude to the designers and 
implementers of particular autonomous systems, particularly with 


regard to timer values. We have done this because we expect that 
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different gateway implementations and different internet 
environments may just have different requirements and goals, so 
that no single strict implementation specification could apply to 
all. However, this does NOT mean that ANY implementation which 
conforms to the specification will work well, or that the areas 
in which we have left latitude are not crucial to performance. 
The fact that some time-out value, for example, is not specified 
here does not mean that everything will work no matter what value 


is assigned. 


Autonomous systems will be assigned 16-bit identification 
numbers (in much the same ways as network and protocol numbers 
are now assigned), and every EGP message header contains one word 
for this number. Zero will not be assigned to any autonomous 
system; rather, the presence of a zero in this field will 


indicate that no number is present. 


We need to introduce the concept of one gateway being a 
NEIGHBOR of another. In the simplest and most common case, we 
call two gateways "neighbors" if there is a network to which each 
has an interface. However, we will need a somewhat more general 


notion of "neighbor" to allow the following two cases: 


a) Two gateways may be regarded as neighbors if they are 


directly connected not by a network (in the usual sense 
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of the term), but by a simple wire, or HDLC line, or some 


similar means of "direct connection". 


b) Two gateways may be regarded as neighbors if they are 
connected by an "internet" which is transparent to them. 
That is, we would like to be able to say that two 
gateways are neighbors even if they are connected by an 
internet, as long as the gateways utilize no knowledge of 
the internal structure of that internet in their own 


packet-forwarding algorithms. 


In order to handle all these cases, let us say that two gateways 
are NEIGHBORS if they are connected by some communications medium 
whose internal structure is transparent to them. (See IEN 184 


for a more general discussion of this notion of neighbor.) 


If two neighbors are part of the same autonomous system, we 
call them INTERIOR NEIGHBORS; if two neighbors are not part of 
the same autonomous system, we call them EXTERIOR NEIGHBORS. In 
order for one system to use another as a transport medium, 
gateways which are exterior neighbors of each other must be able 
to find out which networks can be reached through the other. The 
Exterior Gateway Protocol enables this information to be passed 
between exterior neighbors. Since it is a polling protocol, it 


also enables each gateway to control the rate at which it sends 
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and receives network reachability information, allowing each 
system to control its own overhead. It also enables each system 
to have an independent routing algorithm whose operation cannot 


be disrupted by failures of other systems. 


It must be clearly understood that any autonomous system in 
which routing needs to be performed among gateways within that 
system must implement its own routing algorithm. (A routing 
algorithm is not generally necessary for a simple autonomous 
system which consists of a single stub gateway.) The Exterior 
Gateway Protocol is NOT a routing algorithm. It enables exterior 
neighbors to exchange information which is likely to be needed by 
any routing algorithm, but it does NOT specify what the gateways 
are to do with this information. The "routing updates" of some 
autonomous system’s interior routing algorithm may or may not be 
similar in format to the messages of the exterior gateway 
protocol. The gateways in the DARPA "core" system will initially 
use the GGP protocol (the old Gateway-Gateway protocol) as their 
routing algorithm, but this will be subject to change. Gateways 
in other autonomous systems may use their own Interior Gateway 
Protocols (IGPs), which may or may not be similar to the IGP of 
any other autonomous system. They may, of course, use GGP, but 
will not be permitted to exchange GGP messages with gateways in 


other autonomous systems. 
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It must also be clearly understood that the Exterior Gateway 
Protocol is NOT intended to provide information which could be 
used as input to a completely general area or hierarchical 
routing algorithm. It is intended for a set of autonomous 
systems which are connected in a tree, with no cycles. It does 
not enable the passing of sufficient information to prevent 


routing loops if cycles in the topology do exist. 


The Exterior Gateway Protocol has three parts: (a) Neighbor 
Acquisition Protocol, (b) Neighbor Reachability Protocol, and (c) 
Network Reachability determination. Note that all messages 
defined by EGP are intended to travel only a single "hop". That 
is, they originate at one gateway and are sent to a neighboring 
gateway without the mediation of any intervening gateway. 
Therefore, the time-to-live field should be set to a very small 
value. Gateways which encounter EGP messages in their message 


streams which are not addressed to them may discard them. 
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2 NEIGHBOR ACQUISITION 


Before it is possible to obtain routing information from an 
exterior gateway, it is necessary to acquire that gateway as a 
direct neighbor. (The distinction between direct and indirect 
neighbors will be made ina later section.) In order for two 
gateways to become direct neighbors, they must be neighbors, in 
the sense defined above, and they must execute the NEIGHBOR 
ACQUISITION PROTOCOL, which is simply a standard three-way 


handshake. 


A gateway that wishes to initiate neighbor acquisition with 
another sends it a Neighbor Acquisition Request. This message 
should be repeatedly transmitted (at a reasonable rate, perhaps 
once every 30 seconds or so) until a Neighbor Acquisition Reply 
is received. The Request will contain an identification number 
which is copied into the reply so that request and reply can be 


matched up. 


A gateway receiving a Neighbor Acquisition Request must 


determine whether it wishes to become a direct neighbor of the 
source of the Request. If not, it may, at its option, respond 
with a Neighbor Acquisition Refusal message, optionally 
specifying the reason for refusal. Otherwise, it should send a 


Neighbor Acquisition Reply message. It must also send a Neighbor 
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Acquisition Request message, unless it has done so already. 


Two gateways become direct neighbors when each has sent a 
Neighbor Acquisition Message to, and received the corresponding 


Neighbor Acquisition Reply from, the other. 


Unmatched Replies or Refusals should be discarded after a 
reasonable period of time. However, information about any such 


unmatched messages may be useful for diagnostic purposes. 


A Neighbor Acquisition Message from a gateway which is 
already a direct neighbor should be responded to with a Reply and 


a Neighbor Acquisition Message. 


If a Neighbor Acquisition Reply is received from a 
prospective neighbor, but a period of time passes during which no 
Neighbor Acquisition Message is received from that prospective 
neighbor, the neighbor acquisition protocol shall be deemed 
incomplete. A Neighbor Cease message (see below) should then be 
sent. If one gateway still desires to acquire the other as a 


neighbor, the protocol must be repeated from the beginning. 


If a gateway wishes to cease being a neighbor of a 
particular exterior gateway, it sends a Neighbor Cease message. 
A gateway receiving a Neighbor Cease message should always 


respond with a Neighbor Cease Acknowledgment. It should cease to 
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treat the sender of the message as a neighbor in any way. Since 
there is a significant amount of protocol run between direct 
neighbors (see below), if some gateway no longer needs to be a 


direct neighbor of some other, it is "polite" to indicate this 


fact with a Neighbor Cease Message. The Neighbor Cease Message 
should be retransmitted (up to some number of times) until an 


acknowledgment for it is received. 


Once a Neighbor Cease message has been received, the 
Neighbor Reachability Protocol (below) should cease to be 


executed. 


NOTE THAT WE HAVE NOT SPECIFIED THE WAY IN WHICH ONE GATEWAY 


INITIALLY DECIDES THAT IT WANTS TO BECOME A NEIGHBOR OF ANOTHER. 


While this is hardly a trivial problem, it is not part of the 


External Gateway Protocol. 
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3 NEIGHBOR REACHABILITY PROTOCOL 


It is important for a gateway to keep real-time information 
as to the reachability of its neighbors. If a gateway concludes 
that a particular neighbor cannot be reached, it should cease 
forwarding traffic to that gateway. To make that determination, 


a NEIGHBOR REACHABILITY protocol is needed. The EGP protocol 


provides two messages types for this purpose -- a "Hello" message 


and an "I Heard You" message. 


When a "Hello" message is received from a direct neighbor, 
an "I Heard You" must be returned to that neighbor "immediately". 
The delay between receiving a "Hello" and returning an "I Heard 


You" should never be more than a few seconds. 


At the current time, the reachability determination 
algorithm is left to the designers of a particular gateway. We 


have in mind algorithms like the following: 


A reachable neighbor shall be declared unreachable if, 
during the time in which we sent our last n "Hello"s, we received 
fewer than k "I Heard You"s in return. An unreachable neighbor 
shall be declared reachable if, during the time in which we sent 
our last m "Hello"s, we received at least j "I Heard You"s in 


return. 
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However, the frequency with which the "Hello"s are sent, and 
the values of the parameters k, n, j, and m cannot be specified 
here. For best results, this will depend on the characteristics 
of the neighbor and of the network which the neighbors have in 
common. THIS IMPLIES THAT THE PROPER PARAMETERS MAY NEED TO BE 
DETERMINED JOINTLY BY THE DESIGNERS AND IMPLEMENTERS OF THE TWO 
NEIGHBORING GATEWAYS; choosing algorithms and parameters in 
isolation, without considering the characteristics of the 
neighbor and the connecting network, would not be expected to 


result in optimum reachability determinations. 


The "Hello" and "I Heard You" messages have a status field 
which the sending gateway uses to indicate whether it thinks the 
receiving gateway is reachable or not. This information can be 
useful for diagnostic purposes. It also allows one gateway to 
make its reachability determination parasitic on the other: only 
one gateway actually needs to send "Hello" messages, and the 


other can declare it up or down based on the status field in the 


"Hello". That is, the "passive" gateway (which sends only "I 
Heard You"s) declares the "active" one (which sends only 
"Hello"s) to be reachable when the "Hello"s from the active one 


indicate that it has declared the passive one to be reachable. 
Of course, this can only work if there is prior agreement as to 


which neighbor is to be the active one. (Ways of coming to this 
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"prior agreement" are not part of the Exterior Gateway Protocol.) 


A direct neighbor gateway should also be declared 
unreachable if the network connecting it supplies lower level 
protocol information from which this can be deduced. Thus, for 
example, if a gateway receives an 1822 Destination Dead message 
from the ARPANET which indicates that a direct neighbor is dead, 
it should declare that neighbor unreachable. The neighbor should 
not be declared reachable again until the requisite number of 


Hello/I-Heard-You packets have been exchanged. 


A direct neighbor which has become unreachable does not 
thereby cease to be a direct neighbor. The neighbor can be 
declared reachable again without any need to go through the 
neighbor acquisition protocol again. However, if the neighbor 
remains unreachable for an extremely long period of time, such as 
an hour, the gateway should cease to treat it as a neighbor, 
i.e., should cease sending Hello messages to it. The neighbor 
acquisition protocol would then need to be repeated before it 


could become a direct neighbor again. 


"Hello" and "I Heard You" messages from gateway G to gateway 
G’ also carry the identification number of the NR poll message 


(see below) which G has most recently received from G’. 
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"Hello" and "I Heard You" messages from gateway G to gateway 
G’ also carry the minimum interval in minutes with which G is 


willing to be polled by G’ for NR messages (see below). 


"Hello" messages from sources other than direct neighbors 
should simply be ignored. However, logging the presence of any 


such messages might provide useful diagnostic information. 


A gateway which is going down, or whose interface to the 
network which connects it to a particular neighbor is going down, 
should send a Gateway Going Down message to all direct neighbors 
which will no longer be able to reach it. It should retransmit 
that message (up to some number of times) until it receives a 
Gateway Going Down Acknowledgment. This provides the neighbors 
with an advance warning of an outage, and enables them to prepare 
for it in a way which will minimize disruption to existing 


traffic. 
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4 NETWORK REACHABILITY (NR) MESSAGE 


Terminology: Let gateway G have an interface to network N. 
We say that G is AN APPROPRIATE FIRST HOP to network M relative 
to network N (where M and N are distinct networks) if and only if 


the following condition holds: 


Traffic which is destined for network M, and which arrives 
at gateway G over its network N interface, will be forwarded 
to M by G over a path which does not include any other 


gateway with an interface to network N. 


In short, G is an appropriate first hop for network M 
relative to network N just in case there is no better gateway on 
network N through which to route traffic which is destined for 
network M. For optimal routing, traffic in network N which is 
destined for network M ought always to be forwarded to a gateway 


which is an appropriate first hop. 


In order for exterior neighbors G and G’ (which are 
neighbors over network N) to be able to use each other as packet 
switches for forwarding traffic to remote networks, each needs to 
know the list of networks for which the other is an appropriate 
first hop. The Exterior Gateway Protocol defines a message, 
called the Network Reachability Message (or NR message), for 


transferring this information. 
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Let G be a gateway on network N. Then the NR message which 


G sends about network N must contain the following information: 


A list of all the networks for which G is an appropriate 


first hop relative to network N. 


If G’ can obtain this information from exterior neighbor G, then 
it knows that no traffic destined for networks which are NOT in 
that list should be forwarded to G. (It cannot simply conclude, 
however, that all traffic for any networks in that list ought to 
be forwarded via G, since G’ may also have other neighbors which 
are also appropriate first hops to network N. For example, G and 
G’’ might each be neighbors of G’, but might be "equidistant" 
from some network M. Then each could be an appropriate first 


hop.) 


For each network in the list, the NR message also contains a 
byte which specifies the "distance" (according to some metric 
whose definition is left to the designers of the autonomous 
system of which gateway G is a member) from G to that network. 
This information might (or might not) be useful in the interior 


routing algorithm of gateway G’, or for diagnostic purposes. 


The maximum value of distance (255.) shall be taken to mean 


that the network is UNREACHABLE. ALL OTHER VALUES WILL BE TAKEN 


TO MEAN THAT THE NETWORK IS REACHABLE. 
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If an NR message from some gateway G fails to mention some 
network N which was mentioned in the previous NR message from G, 
it shall be assumed that N is still reachable from G. HOWEVER, 


IF N IS NOT MENTIONED IN TWO SUCCESSIVE NR MESSAGES FROM G, THAT 


SHALL BE TAKEN TO MEAN THAT N IS NO LONGER REACHABLE FROM G. 


This procedure is necessary to ensure that networks which can no 
longer be reached, but which are never explicitly declared 
unreachable, are timed out and removed from the list of reachable 


networks. 


It may often be the case that where G and G’ are exterior 
neighbors on network N, G knows of many more gateway neighbors on 
network N, and knows for which networks those other neighbors are 
the appropriate first hop. Since G’ may not know about all these 
other neighbors, it is convenient and often more efficient for it 
to be able to obtain this information from G. Therefore, the EGP 
NR message also contains fields which allow G to specify the 


following information: 


a) A list of all neighbors (both interior and exterior) of G 
(on network N) which G has reliably determined to be 
reachable. Gateways should be included in this list only 
if G is actively running its neighbor reachability 


protocol with them. 
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b) For each of those neighbors, the list of networks for 
which that neighbor is an appropriate first hop (relative 


to network N). 


c) For each such <neighbor, network> pair, the "distance" 


from that neighbor to that network. 


Thus the NR message provides a means of allowing a gateway 
to "discover" new neighbors by seeing whether a neighbor that it 
already knows of has any additional neighbors on the same 


network. This information also makes possible the implementation 


of the INDIRECT NEIGHBOR strategy defined below. 


A more precise description of the NR message is the 


following. 


The data portion of the message will consist largely of 
blocks of data. Each block will be headed by a gateway address, 


which will be the address either of the gateway sending the 


message or of one of that gateway’s neighbors. Each gateway 
address will be followed by a list of the networks for which that 
gateway is an appropriate first hop, and the distance from that 


gateway to each network. 


Preceding the list of data blocks is: 


a) The address of the network which this message is about. 
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If G and G” are neighbors on network N, then in the NR 
message going from G to G’, this is the address of 
network N. For convenience, four bytes have been 
allocated for this address -- the trailing one, two, or 


three bytes should be zero. 


b) The count (one byte) of the number of interior neighbors 


of G for which this message contains data blocks. By 
convention, this count will include the data block for G 


itself, which should be the first one to appear. 


c) The count (one byte) of the number of exterior neighbors 


of G for which this message contains data blocks. 


Then follow the data blocks themselves, first the block for 
G itself, then the blocks for all the interior neighbors of G (if 
any), then the blocks for the exterior neighbors. Since all 


gateways mentioned are on the same network, whose address has 


already been given, the gateway addresses are given with the 
network address part (one, two, or three bytes) omitted, to save 


space. 


Each block includes a one-byte count of the number of 
networks for which that gateway is the appropriate first hop. In 
the list of networks, each network address is either one, two, or 


three bytes, depending on whether it is a class A, class B, or 
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class C network. No trailing bytes are used. 


It may sometimes be necessary to fragment the NR message. 
The NR message contains a byte indicating the number of this 
fragment (fragments will be numbered from zero), and a byte 
containing the number of the last fragment (NOT the number of 
fragments). If fragmentation is not used, these bytes must both 
be zero. EACH FRAGMENT MUST BE A FULLY SELF-CONTAINED NR 
MESSAGE. That is, each fragment will begin with a count of 
interior and exterior neighbors, and will have some integral 
number of gateway data blocks. The number of data blocks in each 
fragment must correspond to the neighbor counts at the beginning 
of that fragment. However, only the first fragment should begin 


with a data block describing the sending gateway. 


This scheme enables each fragment to be processed 
independently, and requires no complex reassembly mechanisms. It 
also enables processing of a message all of whose fragments have 
not been received. If, after some amount of time and some number 
of retransmissions of a poll, not all fragments have been 
received, the fragments which are present shall be processed as 
if they constituted the complete NR message. (This means that 
networks mentioned only in the missing fragment will retain the 
"distance" values they had in the previous NR message from that 


gateway. However, if no new value for a particular network is 
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received in the next NR message from that gateway, the network 


will be declared unreachable.) 


RFC 827 Bolt Beranek and Newman Inc. 
Eric C. Rosen 


5 POLLING FOR NR MESSAGES 


No gateway is required to send NR messages to any other 
gateway, except as a response to an NR Poll from a direct 
neighbor. However, a gateway is required to respond to an NR 
Poll from a direct neighbor within several seconds (subject to 
the qualification two paragraphs hence), even if the gateway 


believes that neighbor to be down. 


The EGP NR Poll message is defined for this purpose. No 
gateway may poll another for an NR message more often than once 
per minute. A gateway receiving more than one poll per minute 
may simply ignore the excess polls, or may return an error 
message. The Hello and I Heard You messages which gateway G 
sends to gateway G’ indicate the minimum interval which G will 
accept as the polling interval from G’. That is, G’ will not 
guarantee to respond to polls from G that arrive less than that 


interval apart. 


Polls must only be sent to direct neighbors which are 


declared reachable by the neighbor reachability protocol. 


An NR Poll message contains an identification number chosen 
by the polling gateway. The polled gateway will return this 


number in the NR message it sends in response to the poll, to 


enable the polling gateway to match up received NR messages with 
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polls. It will be the responsibility of the polling gateway to 
choose an identification number which is sufficiently "unique" to 
allow detection of out-of-date NR messages which may still be 
floating around the network. Since polls are relatively 
infrequent, this is not expected to be much of a problem. 
However, to aid in choosing an identification number, the Hello 
and I Heard You messages carry the identification number of the 
last NR poll received from the neighbor to which they are being 


sent. 


In general, a poll should be retransmitted some number of 
times (with a reasonable interval between retransmissions) until 


an NR message is received. IF NO NR MESSAG 


Gl 


IS RECEIVED AFTER 


THE MAXIMUM NUMBER OF RETRANSMISSIONS, THE POLLING GATEWAY SHOULD 


ASSUME THAT THE POLLED GATEWAY IS NOT AN APPROPRIATE FIRST HOP 


FOR ANY NETWORK WHATSOEVER. The optimum parameters for the 
polling/retransmission algorithm will be dependent on the 
characteristics of the two neighbors and of the network 


connecting them. 


If only some fragments of an NR message are received after 
the maximum number of retransmissions, the fragments that are 
present shall be treated as constituting the whole of the NR 


message. 
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Received NR messages whose identification numbers do not 
match the identification number of the most recently sent poll 
shall be ignored. There is no provision for multiple outstanding 


polls to the same neighbor. 
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6 SENDING NR MESSAGES 


In general, NR messages are to be sent only in response to a 
poll. However, between two successive polls from an exterior 
neighbor, a gateway may send one and only one unsolicited NR 
message to that neighbor. This gives it limited ability to 
quickly announce network reachability changes that may have 
occurred in the interval since the last poll. Excess unsolicited 


NR messages may be ignored, or an error message may be returned. 


An NR message should be sent within several seconds after 
receipt of apoll. Failure to respond in a timely manner to an 
NR poll may result in the polling gateway’s deciding that the 


polled gateway is not an appropriate first hop to any network. 


NR messages sent in response to polls carry the 
identification number of the poll message in their 
"identification number" fields. Unsolicited NR messages carry 


the identification number of the last poll received, and have the 
"unsolicited" bit set. (Note that this allows for only a single 


unsolicited NR message per polling period.) 


To facilitate the sending of unsolicited NR messages, the NR 
poll message has a byte indicating the polling interval in 


minutes. 
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Polls from non-neighbors, from neighbors which are not 
declared reachable, or with bad IP source network fields, should 
be responded to with an EGP error message with the appropriate 
"reason" field. If G sends an NR poll to G’ with IP source 
network N, and G’ is not a neighbor of G on its interface to 
network N (or G’ does not have an interface to network N), then 


the source network field is considered "bad". 


Duplicated polls (successive polls with the same 
identification number) should be responded to with duplicates of 
the same NR message. If that message is fragmented, the same 
fragments shall be sent each time. Note that there is no 
provision for handling multiple outstanding polls from a single 
neighbor. NOTE THAT IF THE SAME FRAGMENTS ARE NOT SENT IN 
RESPONSE TO DUPLICATED POLLS, INCORRECT REASSEMBLY WILL BE THE 
PROBABLE RESULT. If fragmentation is not being used, however, 
then no harm should result from responding to a duplicate poll 


with a different (presumably more recent) NR message. 


一 26 - 
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7 INDIRECT NEIGHBORS 


Becoming a "direct neighbor" of an exterior gateway requires 
three steps: (a) neighbor acquisition, (b) running a neighbor 
reachability protocol, and (c) polling the neighbor periodically 
for NR messages. Suppose, however, that gateway G receives an NR 
message from G’, in which G’ indicates the presence of other 
neighbors Gl, ..., Gn, each of which is an appropriate first hop 
for some set of networks to which G’ itself is not an appropriate 


first hop. Then G should be allowed to forward traffic for those 


networks directly to the appropriate one of Gl, ..., Gn, without 
having to send it to G’ first. In this case, G may be considered 
an INDIRECT NEIGHBOR of Gl, ..., Gn, since it is a neighbor of 


these other gateways for the purpose of forwarding traffic, but 
does not perform neighbor acquisition, neighbor reachability, or 
exchange of NR messages with them. Neighbor and network 
reachability information is obtained indirectly via G’, hence the 
designation "indirect neighbor". We say that G is an indirect 


neighbor of Gl, ..., Gn VIA G’. 


If G is an indirect neighbor of G’ via G’’, and then G 
receives an NR message from G’’ which does not mention G’, G 


should treat G’ as having become unreachable. 
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8 HOW TO BE A STUB GATEWAY 


The most common application of EGP will probably be its use 
to enable a stub gateway to communicate with one of the DARPA 
core gateways, so as to enable data flow between networks 
accessible only via the stub and networks accessible only via the 
system of core gateways. As discussed previously, a stub gateway 
can be considered to be a one-gateway internet system with no 
interior neighbors. It is probably used to interface a local 
network or networks to a long range transport network (such as 
ARPANET or SATNET) on which there is a core gateway. In this 
case, the stub will not want the core gateways to forward it any 
traffic other than traffic which is destined for the network or 
networks which can be reached only via the stub. In general, the 
stub will not want to perform any services for the internet 
transport system which are not needed in order to be able to pass 
traffic to and from the networks that cannot be otherwise 


reached. 


The stub should have tables configured in with the addresses 
of a small number of the core gateways (no more than two or 
three) with which it has a common network. It will be the 
responsibility of the stub to initiate neighbor acquisition with 
these gateways. When a stub and a core gateway become direct 


neighbors, the core gateway will begin sending Hello messages. 
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When the stub declares the core gateways which are direct 


neighbors to be reachable, it should poll those gateways for NR 
messages at a rate not to exceed once per minute (or as specified 
in the Hello messages from the core gateways). The core gateways 


will also poll the stub for NR messages. 


The NR message sent by the stub should be the simplest 
allowable. That is, it should have only a single data block, 
headed by its own address (on the network it has in common with 
the neighboring core gateway), listing just the networks to which 
it is an appropriate first hop. These will be just the networks 


that can be reached no other way, in general. 


The core gateways will send complete NR messages, containing 
information about all other gateways on the common networks, both 
core gateways (which shall be listed as interior neighbors) and 


other gateways (which shall be listed as exterior neighbors, and 


may include the stub itself). This information will enable the 


stub to become an indirect neighbor of all these other gateways. 


That is, the stub shall forward traffic directly to these other 
gateways as appropriate, but shall not become direct neighbors 


with them. 


The core gateways will report distances less than 128 if the 


network can be reached without leaving the core system (i.e., 
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without traversing any gateway other than a core gateway), and 


greater than or equal to 128 otherwise. 


The stub should NEVER forward to any (directly or 
indirectly) neighboring core gateway any traffic for which that 
gateway is not an appropriate first hop, as indicated in an NR 
message. Of course, this does not apply to datagrams which are 
using the source route option; any such datagrams should always 
be forwarded as indicated in the source route option field, even 
if that requires forwarding to a gateway which is not an 


appropriate first hop. 


If the direct neighbors of a stub should all fail, it will 
be the responsibility of the stub to acquire at least one new 
direct neighbor. It can do so by choosing one of the core 
gateways which it has had as an indirect neighbor, and executing 
the neighbor acquisition protocol with it. (It is possible that 
no more than one core gateway will ever agree to become a direct 


neighbor with any given stub gateway at any one time.) 


If the stub gateway does not respond in a timely manner to 
Hello messages from the core gateway, it may be declared 
unreachable. If it does not respond to NR poll messages in a 
timely manner, its networks may be declared unreachable. In both 


these cases, the core gateways may discard traffic destined for 
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those networks, returning ICMP "destination network unreachable" 


to the source hosts. 


The stub gateway is expected to fully execute the ICMP 
protocol, as well as the EGP protocol. In particular, it must 
respond to ICMP echo requests, and must send ICMP destination 
dead messages as appropriate. It is also required to send ICMP 


Redirect messages as appropriate. 
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9 LIMITATIONS 


It must be clearly understood that the Exterior Gateway 
Protocol does not in itself constitute a network routing 
algorithm. In addition, it does not provide all the information 
needed to implement a general area routing algorithm. If the 
topology of the set of autonomous systems is not tree-structured 
(i.e., if it has cycles), the Exterior Gateway Protocol does not 


provide enough topological information to prevent loops. 


If any gateway sends an NR message with false information, 
claiming to be an appropriate first hop to a network which it in 


fact cannot even reach, traffic destined to that network may 


never be delivered. Implementers must bear this in mind. 
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NEIGHBOR ACQUISITION MESSAGE 


0 1 2 3 

Oo Te 2) Be 24 56 98-950: L 28 A S50 78: 900. Ay 2 8 4 Be 67 8: 9.0. U 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! EGP Version + ! Type ! Code ! Info 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Checksum ! Autonomous System # ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Identification # ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Description: 


The Neighbor Acquisition messages are used by interior and 
exterior gateways to become neighbors of each other. 


EGP Version # 


1 
Type 
3 
Code 
Code = 0 Neighbor Acquisition Request 
Code = 1 Neighbor Acquisition Reply 
Code = 2 Neighbor Acquisition Refusal (see Info field) 
Code = 3 Neighbor Cease Message (see Info field) 
Code = 4 Neighbor Cease Acknowledgment 
Checksum 


The EGP checksum is the 16-bit one’s complement of the one’s 
complement sum of the EGP message starting with the EGP 
version number field. For computing the checksum, the 
checksum field should be zero. 


Autonomous System + 


This 16-bit number identifies the autonomous system 
containing the gateway which is the source of this message. 
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Info 

For Refusal message, gives reason for refusal: 
0 Unspecified 
1 Out of table space 
2 Administrative prohibition 

For Cease message, gives reason for ceasing to be neighbor: 
O Unspecified 
1 Going down 
2 No longer needed 

Otherwise, this field MUST be zero. 


Identification Number 


An identification number to aid in matching requests and 
replies. 
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NEIGHBOR HELLO/I HEARD YOU MESSAGE 


1 2 3 


01.2 34 29. 36: FBG LS AS 62 8 LL SA o 16 FB. 90: 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


! EGP Version # ! Type ! Code ! Status ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Checksum ! Autonomous System # ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Sequence # 'Min Poll Intvl ! Zero 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Last Poll Id # ! 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

Description: 


Exterior neighbors use EGP Neighbor Hello and I Heard You 
Messages to determine neighbor connectivity. When a gateway 
receives an EGP Neighbor Hello message from a neighbor it 
should respond with an EGP I Heard You message. 


EGP Version # 


Code 


Code = 0 for Hello 
Code 1 for I Heard you 


Checksum 


The EGP checksum is the 16-bit one’s complement of the one’s 
complement sum of the EGP message starting with the EGP 
version number field. For computing the checksum, the 
checksum field should be zero. 


Autonomous System + 


This 16-bit number identifies the autonomous system 
containing the gateway which is the source of this message. 
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Sequence Number 


A sequence number to aid in matching requests and replies. 


Status 


0 
1 
2 


No status given 

You appear reachable to me 

You appear unreachable to me due to neighbor 
reachability protocol 

You appear unreachable to me due to network 
reachability information (such as 1822 "destination 
dead" messages from ARPANET) 

You appear unreachable to me due to problems 

with my network interface 


Last Poll Id Number 


Minimum 


The identification number of the most recently received 
NR poll message from the neighbor to which this message 
is being sent. 


Polling Interval 


This gateway should not be polled for NR messages more 
often than once in this number of minutes. 
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NR POLL Message 


0 1 2 3 

0- 1 2B 4 SiGe 1,78: 9 O de 2 3 eb Gy "89 OF lr BB) Ay SiG: Y 8 90 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! EGP Version # ! Type ! Code ! Unused 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Checksum ! Autonomous System # ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! IP Source Network ! Interval ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Identification # ! 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Description: 
A gateway that wants to receive an NR message from an 
Exterior Gateway will send an NR Poll message. Each gateway 
mentioned in the NR message will have an interface on the 


network that is in the IP source network field. 


EGP Version # 


Checksum 


The EGP checksum is the 16-bit one’s complement of the one’s 
complement sum of the EGP message starting with the EGP 
version number field. For computing the checksum, the 
checksum field should be zero. 


Autonomous System # 


This 16-bit number identifies the autonomous system 
containing the gateway which is the source of this message. 
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Identification Number 


An identification number to aid in matching requests and 
replies. 


IP Source Network 


Each gateway mentioned in the NR message will have an 
interface on the network that is in the IP source network 
field. The IP source network is coded as one byte of 
network number followed by two bytes of zero for class A 
networks, two bytes of network number followed by one byte 
of zero for class B networks, and three bytes of network 
number for class C networks. 


Interval 


The polling interval in minutes. 
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NETWORK REACHABILITY MESSAGE 


0 1 2 3 
OL. 2 344 9536: P89 Or Ln 2 3 AS 628 9 Or hk 2 3 2006. PB. 90: 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! EGP Version # ! Type ! Code IU! Zeroes 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Checksum ! Autonomous System # ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! Fragment + '# of last frg. ! Identification # ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! IP Source Network ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! # of Int Gwys ! # of Ext Gwys ! 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


! # of Nets ! ; # of nets for 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 Gateway 1 

! Gateway 1 IP address (without network +) ! ; 1, 2 or 3 bytes 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! net 1,1 ll 1, 2 or 3 bytes 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! distance ! 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! net 1,2 IIIIIIIIIIIIIIIIIIIIIIIIIIIIL > 1, 2 or 3 bytes 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! distance ! 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! net l,m ee ee ee a pO ee Ae Pek PN KN) PO PE) A Pi el BO FN i E ; m nets reachable 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; via Gateway 1 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! # of nets ! ¿number of nets for Gateway n 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! Gateway n IP address (without network +) 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! net n,1 IIIIIIIIIIIIIIIIIIIIIIIIIIII ; 1, 2 or 3 bytes 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

! distance ! 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! net n,2 I 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
! distance ! > 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 $ 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! net n,m 人 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
! distance ! 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


pa alo 
十 一 十 


So se 
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, 2 or 3 bytes 
一 十 一 十 一 十 一 十 一 十 一 十 


m nets reachable 
via Gateway n 
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Description: 


Eric C. Rosen 


The Network Reachability message (NR) is used to discover 


which networks may be reached through Exterior Gateways. The 
message is sent in response to an NR Poll message. 


EGP Version # 


Checksum 


The EGP checksum is the 16-bit one’s complement of the one’s 
complement sum of the EGP message starting with the EGP 
version number field. For computing the checksum, the 
checksum field should be zero. 


Autonomous System # 


U 


This 16-bit number identifies the autonomous system 
containing the gateway which is the source of this message. 


(Unsolicited) bit 


This bit is set if the NR message is being sent unsolicited. 


Identification Number 


The identification number of the last NR poll message 
received from the neighbor to whom this NR message is being 
sent. This number is used to aid in matching polls and 
replies. 


Fragment Number 


Which Fragment this is in the NR Message. Zero, if 
fragmentation is not used. 
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Number of Last Fragment 
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Number of the last fragment in the NR Message. Zero, if 
fragmentation is not used. 


IP Source Network 


# of 


# of 


Each gateway mentioned 
interface on the network 
field. 


Interior Gateways 


The number of interior 
message. 


Exterior Gateways 


The number of exterior 
message. 


Networks 


The number of networks 


Gateway IP address 


in 


the 


NR message will have an 


that is in the IP source network 


gateways that are mentioned in this 


gateways that are mentioned in this 


for 


which the gateway whose IP 
address immediately follows is the appropriate first hop. 


1, 2 or 3 bytes of Gateway IP address (without network #). 


Network address 


1, 2, or 3 bytes of network address of network which can be 


reached via the preceding gateway. 


Distance 


1 byte of distance in # of hops. 


42 


RFC 


0 

0 1 
十 一 十 一 
! EG 
十 一 十 一 
! 
十 一 十 一 
! Er 
十 一 十 一 
! 
十 一 十 一 


Desc 


EGP 


Chec 


Auto 
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EGP ERROR MESSAGE 


dl 2 3 
234567890123456789012345678<9021 
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ription: 
An EGP Error Message is sent in response to an EGP Message 
that has a bad checksum or has an incorrect value in one of 


its fields. 


Version # 


ksum 


The EGP checksum is the 16-bit one’s complement of the one’s 
complement sum of the EGP message starting with the EGP 
version number field. For computing the checksum, the 
checksum field should be zero. 


nomous System # 


This 16-bit number identifies the autonomous system 
containing the gateway which is the source of this message. 
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Sequence Number 


A sequence number assigned by the gateway sending the error 
message. 


Error Type 

The Type of the EGP message that was in error. 
Error Code 

The Code of the EGP message that was in error. 
Identification number of erroneous message 

The Sequence number of the EGP message that was in error. 
Reason 


The reason that the EGP message was in error. The following reasons 
are defined: 


- unspecified 

- Bad EGP checksum 

- Bad IP Source address in NR Poll or Response 
- Undefined EGP Type or Code 

- Received poll from non-neighbor 

Received excess unsolicted NR message 

- Received excess poll 

- Erroneous counts in received NR message 

- No response received to NR poll 

- Not all fragments of NR message received 
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